Lawful interception of end-to-end encrypted data traffic

ABSTRACT

A method of facilitating the lawful interception of an IP session between two or more terminals  12,13 , wherein session uses encryption to secure traffic. The method includes storing a key allocated to at least one of terminals  12,13  or to at least one of the subscribers using one of the terminals  12,13 , at the terminal  12,13  and at a node  5,8  within a network  1,6  through which session is conducted, or a node coupled to that network. Prior to the creation of session, a seed value is exchanged between the terminal  12,13  at which the key is stored and node  5,8 . The key and the seed value are used at both the terminal  12,13  and the node  5,8  to generate a pre-master key. The pre-master key becomes known to each of the terminals  12,13  involved in the IP session and to the network node  5,8 . The pre-master key is used, directly or indirectly, to encrypt and decrypt traffic associated with IP session.

FIELD OF THE INVENTION

The present invention relates to a method and apparatus for facilitatinglawful interception of Data traffic, for example IP traffic.

BACKGROUND TO THE INVENTION

It is now possible to establish various forms of connection over theInternet including data connections as well as voice and video telephonyconnections. As the speed and extent of the Internet increases, the useof voice and video telephony can be expected to grow. Whilst currenttechnology tends to restrict IP multimedia sessions to computerterminals coupled to the Internet, tomorrow's technology will providefor IP multimedia sessions between small dedicated telephony terminals,and other mobile devices such as PDAs, palmtop computers etc.

In order to allow such devices to gain widespread acceptance, a keyissue which must be addressed is that of security. The two main securityconcerns are the avoidance of unauthorised eavesdropping, and the needto authenticate terminals involved in a communication (i.e. to ensurethat the terminal which a “subscriber” connects to is the terminal whichthe subscriber intends to connect to and vice versa). However, theseconcerns are not unique to IP multimedia, and are common to manydifferent forms of IP communication. Several protocols exist forsecuring data traffic using encryption and/or authentication.

One such security protocol is known as IPsec (IETF RFC2401). In order toallow IPsec packets to be properly encapsulated and decapsulated it isnecessary to associate security services and a key between the trafficbeing transmitted and the remote node which is the intended recipient ofthe traffic. The construct used for this purpose is a “SecurityAssociation” (SA). A second security protocol is known as SRTP (SecureReal-Time Protocol)—see draft-ietf-avt-srtp-02.txt. It is expected thatthe third generation mobile network architecture known as 3GPP willadopt SRTP as the protocol for securing IP Multimedia traffic. Ofcourse, other protocols such as IPsec may be used in other mobilenetwork architectures.

In the Internet draft “draft-ietf-msec-mikey-00.txt”, a key managementscheme known as Multimedia Internet KEYing (MIKEY) is described for usein real-time applications. The scheme provides for the creation of aSecurity Association (SA) and the distribution of a Pre-Master Key(PMK). (Actually, MIKEY denotes these keys “TEK Generating Keys”, butPMK is a more common term and will be used throughout as the invention'suse is not restricted to MIKEY.) The PMK is used to derive aTraffic-Encrypting Key (TEK) for each crypto session. More specifically,the TEK is used as the key input to the chosen security protocol, i.e.SRTP.

SUMMARY OF THE INVENTION

Traditional circuit switched telephone networks make provision for thelawful interception of telephone calls. Such interception must beinstigated by the appropriate authorities and is an important weaponagainst fraud and other crimes. Understandably, it is desirable to makeprovision for the lawful interception of IP sessions (whether pure data,VoIP, video, etc). However, this presents a potential problem as the IPsecurity protocols which will be used have been designed to provideterminal-to-terminal security involving strong encryption.

If the a protocol such as the MIKEY proposal is implemented, securitymechanisms will rely upon the use of a Pre-Master Key (PMK) which isagreed upon by the parties to an IP session. The PMK may be proposed bythe initiator of the session and accepted (or rejected) by theresponder, or may be generated using values exchanged between theparties to the session. The agreement of the PMK forms part of an IPMulti-Media key management function. Following the agreement of the PMK,the Multi-Media key management function may encrypt the PMK with asecret key which it shares with the responder, or with the public key ofthe responder, or the initiator may calculate a Diffie-Hellman modularexponentiation to obtain the PMK. It will be appreciated that in orderto intercept traffic associated with that session, a third party musthave knowledge of the PMK

It is an object of the present invention to facilitate the lawfulinterception of an IP session which requires the parties involved in thesession to agree upon a PMK for use in securing traffic sent over thesession.

According to a first aspect of the invention there is provided a methodof facilitating the lawful interception of a data session between two ormore terminals, wherein said session uses encryption to secure traffic,the method comprising:

-   -   storing a key allocated to at least one of said terminals, at        the terminal and at a node within a network through which said        session is conducted or at a node coupled to that network;    -   prior to setting up a session between the terminals, exchanging        a seed value between the terminal at which the key is stored and        said node;    -   using the key and the seed value at the terminal to generate a        pre-master key, wherein the pre-master key also becomes known to        the or each other terminal involved in the data session; and    -   directly or indirectly using said pre-master key to encrypt and        decrypt traffic associated with said session.

According to a second aspect of the invention there is provided a methodof securing data transmitted between a plurality of terminals, each ofwhich is attached to a communications network, at least one of theterminals having allocated to it a home network, the method comprising:

-   -   sending a seed value from the home network to the at least one        terminal, via the corresponding communications network, as part        of a call signalling level authentication procedure; and    -   using said seed value at the at least one terminal to generate        one or more traffic encryption keys for use in the end-to-end        encryption of traffic associated with a call between terminals.

This method preferably comprises storing a secret key at said mobileterminal and in the home network, and sending that key from the homenetwork to said mobile network for use in said authentication procedure,the key also being used by the wireless terminal to generate saidtraffic encryption key(s). The step of generating one or more trafficencryption keys comprises performing a key exchange procedure betweenthe terminals.

Preferably, the Session Initiation Protocol is used to setup and controlcalls between terminals, and the method comprises sending said randomvalue from said home network to the mobile terminal, via a P-CSCF nodeof said mobile network. More preferably, said call signalling levelauthentication procedure is an IMS AKA procedure.

Preferably, the method further comprises forwarding said random value toa lawful interception authority to allow that authority to compute thetraffic encryption key(s), whereby when a call is setup encryptedtraffic can be forwarded to the authority for decryption.

Further aspects and preferred features of the invention are set out inthe attached claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically a communications network for enablingan IP session to be established between two mobile terminals;

FIG. 2 shows signalling exchanged between the mobile terminals of FIG. 1and a network node, the signalling being associated with theestablishment of a shared secret;

FIG. 3 is a flow diagram illustrating a method of intercepting an IPsession;

FIG. 4 illustrates signalling associated with a Diffie-Hellman exchange;

FIG. 5 illustrates a network structure where UEs are registered withvisited networks;

FIG. 6 illustrates an AKA protocol;

FIG. 7 illustrates modules of a UE associated with authentication andsecurity;

FIG. 8 illustrates the steps in setting up a SIP call; and

FIG. 9 illustrates in detail the steps in setting up a SIP call betweentwo subscribers attached to different 3G networks.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

There is illustrated in FIG. 1 a communications system comprising amobile telecommunications network 1 which for the purpose of thisdiscussion is assumed to be a 3GPP (or UMTS) network. Within the 3GPPnetwork 1 are a UMTS Terrestrial Radio Access Network (UTRAN) 2 and aGPRS network 3. The GPRS network comprises one or more Serving GPRSSupport nodes (SGSNs) 4 and one or more Gateway GPRS Support Nodes(GGSNs) 5. The role of the SGSN 4 is to maintain subscription data(identities and addresses) and to track the location of user equipment(UB) within the network. The role of the GGSN 5 is to maintainsubscription information and allocated IP addresses and to track theSGSN 4 to which UEs are attached. The network 1 also contains subscriberdatabases, e.g. HSS or AuC/HLR 14, maintaining subscription informationabout users, keying information for security etc.

FIG. 1 also illustrates a second mobile telecommunications network 6which is also assumed to be a 3GPP network. This network also comprisesSGSNs 7 and GGSNs 8 forming part of a GPRS network 9, and a UTRAN 10.The two GGSNs 5,8 are both coupled to an IP network 11. Two UEs 12,13are attached to the first and second networks 1,6 respectively. 3GPPprovides UEs with an “always connected” service such that as long as UEsare registered with a network (home or visited) they are allocated IPaddresses and can receive and send data without the need for aconnection to be established. A call set-up protocol, e.g. the SessionInitiation Protocol (SIP), may be used to establish a multimedia sessionbetween the two UBs 12,13 of FIG. 1. (SIP will be described in moredetail later. Here it is only noted that SIP can be used to set upsessions by “inviting” other users to join sessions.) Within the GPRSnetworks 3,9 it is the GGSNs 5,8 which implement the policy of thenetwork operator, e.g. which subscribers can access which services,subscriber priorities, etc.

Typically, when a subscriber registers with the operator of a 3GPPnetwork, he or she receives a Subscriber Identity Module (SIM) card onwhich is stored a unique International Mobile Subscriber Identity (IMSI)code. In addition to the IMSI it is proposed here that a secret key k isalso stored on the SIM card. This key is known only to the networkoperator and to the user (or rather to the user's SIM card) and a copyof the key is stored in a Subscriber Database (SDB) 14 attached to forexample the HSS or HLR/AuC of the subscriber's home network. Also storedon the subscriber's SIM card (or possibly in a memory of thesubscriber's UE) and in the SDB 14 is a pseudo-random function such as akeyed hash (or MAC, Message Authentication Code) such as SHA-1 or MD5 orthe 3GPP Milenage algorithm (see 3GPP TS 35.205-35.209 for the latter).

For the reasons set out above, it may be necessary to intercept an IPsession between the two UEs 12,13. Interception is carried out asfollows.

Assume that a session is initiated by a first of the UEs 12. The UE 12sends an invite message via the GGSN 5 to which it is attached. Theinvite message identifies both the initiating UE 12 and the respondingUE; in this case UE 13. At this stage, the session initiation is placedon hold, and the database 14 is inspected to see if it holds a key forthe initiating UE 12. If no key is contained in the database 14, thesession initiation is not allowed to continue and a notification messagemay be returned to the UE 12. If on the other hand a key is held for theUE 12, the SDB 14 generates a random number or “nonce” and returns thisto the UE 12 via the GGSN 5. The nonce provides a seed value for furthercomputations. The nonce need not be secured (i.e. encrypted) fortransmission to the UE 12. Both the UE 12 and the SDB 14 then compute aPre-Master Key (PMK), k_m, by applying the pseudo-random function to theshared key and the nonce, i.e.k _(—) m=PRF(k,nonce).

Once the PMK has been established, the GGSN 5 routes the invite messageto the home network 6 of the responding UE 13 via an “IP MultimediaSubsystems” 15,16 (operated respectively by the operators of the mobilenetworks 1,6). The invite message is received by the responding UE 13via the GGSN 8 to which it is connected. Assuming that the responding UE13 chooses to accept the session setup request, phase 1 of a keyexchange protocol, e.g. MIKEY, is initiated. This requires that the UE12 send to the UE 13 the PMK which has been established by the UE 12 inconjunction with the SDB 14. The PMK may be encrypted with a secret keyshared between the UEs 12,13 or with the public key of the responding UE13 (SRTP does not specify how the PMK should be exchanged or negotiated,it only requires that a common, secret PMK must be known to the parties,e.g. by means of using MIKEY). In either case, the result is that theUEs 12,13 and the SDB 14 to which the originating UE 12 is attached, allknow the PMK at the end of phase 1.

In phase 2 of the key exchange protocol, the UEs 12,13 use the sharedPMK to generate a Traffic-Encrypting Key (TEK). The procedure involvedis set out in the MIKEY draft referred to above. As the algorithm andparameters (including the PMK) required to calculate the TEK are knownto the SDB 14, the SDB can compute the TEK. Once the TEK is generated,the IP session can begin. Traffic is encrypted and decrypted, using e.g.SRTP, at the UEs 12,13 using the TEK. In some cases, a pair of TEKs maybe generated in phase 2 of the key exchange protocol, with a first ofthe TEKs being used to encrypt traffic in one direction and the secondTEK being used to encrypt traffic in the opposite direction.

It will be appreciated that IP traffic associated with the session willalways pass through the GGSN 5. As such, the GGSN 5 is able to interceptthe traffic and, if given the keys from the SDB 14, decrypt it using theTEK(s). The decrypted traffic can then be passed to a governmentauthority such as the police. Alternatively, during the session setupphase, the network operator may forward the TEK(s) to the governmentauthority. Traffic which is intercepted at the GGSN 5 is thereforepassed directly to the government authority which can decrypt thetraffic using the previously received TEK(s).

The signalling associated with the PMK generation and exchange phase isillustrated in FIG. 2. FIG. 3 is a flow diagram further illustrating themechanism. It will be appreciated that the GGSN will only be given theTEK if lawful interception is authorised for the IP session.

Agreements may be made between governments and network operators toenable a government authority to intercept an IP session initiated by aUE outside the authority of an interested government. In this case, aPMK generated at a node of an external network may be sent from theexternal network to the network under the authority of the interestedgovernment. The PMK can then be used to intercept the IP session.

Whilst the above description has been concerned with UEs and mobilenetworks, the present invention is not to be considered limited tomobile networks. The invention is also applicable to IP sessionsextending between terminals coupled to fixed line networks and to otherwireless networks, and to IP sessions extending between terminalscoupled to different network types (e.g. a mobile to fixed line terminalsession). The invention may be applied to UEs connected to the sameaccess network as well as to different access networks.

In a modification to the procedure described above, rather than using apseudo-random function to generate the PMK from the nonce and the sharedsecret key, an encryption function such as Data Encryption Standard(DES) or Advanced Encryption Standard (AES) may be used. In anothermodification, rather than using the entire shared secret key k togenerate the PMK, only a portion or modified version of the sharedsecret key may be used. In yet another modification, the TEK(s) is (are)derived from the PMK via one or more intermediate encryption keys.

It will be appreciated by the person of skill in the art that variousmodifications may be made to the above described embodiment withoutdeparting from the scope of the present invention. For example, ratherthan the initiating UE generating the PMK, the PMK may be generatedusing a Diffie-Hellman exchange between the participating UEs.

Let (G,*) be a commutative group. For a natural number x, and g in G,letg^x=g*g* . . . *g(x times). Consider the problem of computing y=g^x, given g and x. By a“binary” method, this can be done using log_(—)2(x) group operations(“multiplications” and “squarings”). Now consider the inverse problem,given y (=g^x) and g, find x. This is known as the (discrete) logarithmproblem. If the group (G,*) comprises real numbers under multiplication,then the logarithm is almost as easy to compute as g^x itself. However,in some cases, e.g. when (G,*) is

-   -   1. the integers under multiplication modulo a suitable prime        number, p    -   2. points on a suitable elliptic curve under addition, there        exists no known, efficient algorithm for the logarithm problem        (the best general method has a running time proportional to        roughly |G|^(½) where |G| is the size of the group), though the        “forwards exponentiation” is still efficiently computable. Based        on the (assumed) intractability of the discrete logarithm        problem, Diffie-Hellman uses the following key agreement method.        Let (G,*) be such a “hard” group and let g be a designated        element of G. The protocol is as illustrated in FIG. 4 below for        two terminals UE_(A) and UE_(B). (Note that by commutativity:        yB^xA=(g^xB)^xA=(g^xA)^xB=yA^xB.) The result of the        Diffie-Hellman exchange is a shared secret key k which provides        a PMK.

In practice, for security reasons k may not be used directly to encrypttraffic, but rather some traffic encryption key (TEK) is derived fromthe PMK k (e.g. by taking a hash of the PMK). For complete security,UE_(A) and UE_(B) will need to authenticate one another, either by meansof a previously known shared secret key, or by digital signatures andcertificates.

By combining the use of a nonce exchanged between the network and a UE,and a Diffie-Hellman exchange, a secure mechanism for obtaining a sharedsecret key and which allows for lawful interception is obtained. Thisinvolves the sending of a nonce from the SDB to the initiating UE. Boththe UE and the SDB apply the pseudo-random function to the nonce and theshared secret key to generate the value x. The UE generates anexponentiation of a value g to the power x, according to g^x, where g isa non-secret value known at least to the participating UEs and to theSDB. The computed value (a first cross-parameter) is sent to theresponding UE. The responding UB receives a nonce from the SDB to whichit is connected and uses this to generate a shared secret key y. It thencomputes g^y (a second cross-parameter), and returns this to theinitiating UE. Both parties now calculate a PMK according to k_m=g^(xy).During this process, a node such as the GGSN can intercept or “sniff”the value g^y sent from the responding UE to the initiating UE. As longas the GGSN already knows the value of x (e.g. if given to if it fromthe SDB), it too can compute the PMK. This enables the GGSN to decrypttraffic. Again, in a preferred alternative, the GGSN simply forwardstraffic to the intercept-centre, with the keys being forwardedseparately to that centre, and the decryption is performed at theintercept centre.

In the case where a UE has roamed out of the coverage area of its homenetwork (i.e. the network with which the UE has a subscription—see FIG.5) into the coverage area of a visited network, it will be appreciatedthat the secret key k may be known only to the UE and to the homenetwork. For security reasons, it is preferred that the key k does notbecome known to the visited network. However, the possibility for lawfulinterception within the visited network may still be a requirement. Inthis case, the nonce can be sent from the home network to the UE via thevisited network. At the same time, the home network computes the PMK andsends this to the visited network. Thus, the visited network can decrypttraffic encrypted with the PMK (or a TEK derived from the PMK). In thecase where a Diffie-Hellman exchange is used, the visited network issent the value x by the home network, and can intercept the value g^y,thus allowing the visited network to compute the PMK {g^(xy)}.

The 3G (UMTS) cellular standard supports authentication andkey-agreement between a mobile terminal (UE) and the network (the radionetwork controller (RNC) node). A part of the protocol, known as theauthentication and key agreement (AKA) protocol, is used to establish akey to protect traffic in the link between the UE and the RNC. However,the prior art protocols do not consider using this key, or keys derivedthereform, to secure the traffic outside of this link. It is proposedhere to use the key to secure the traffic end-to-end, i.e. from userterminal to user terminal.

AKA operates as follows. The mobile terminal UE and its home networkshare a secret key k_(i) (stored on the UE's SIM card and in theoperator's SDB, i.e. HSS or HLR/AuC). When the UE connects to a visitednetwork, the visited network asks the home network for a “quintet”comprising five values. Only three of these values, rand, XRES, andk_(c), are relevant here. The value rand is a random value generated bythe home network. The value k_(c) can be equated to the secret key x andis derived by applying a key derivation function KDF (typically a blockcipher function using k_(i) as key) to the secret key k_(i) and therandom value rand, i.e. k_(c)=KDF(k_(i), rand). XRES is derived by thehome network as XRES=ƒ(ki,rand), where the function ƒ is typically apublicly known function.

The visited network forwards the value rand to the UE. The UB knows thefunctions ƒ and KDF and computes k_(c) and a result RES. The value RESis returned to the visited network where it is compared with the valueXRES. Assuming that XRES=RES, the UB is authenticated to the visitednetwork. A similar procedure would be performed for some other mobileterminal, connected to a visited network, with which the first mentionedterminal wishes to communicate. Using a Diffie-Hellman exchange, the PMKbecomes known to both terminals. As a visited network can sniffg^k_(c(A or B)), it can derive the PMK (g^(k_(c(A or B))k_(c(B or A))).It is also possible for a visited network to verify that a terminal isusing the agreed key k_(c), and is not trying to cheat by using someother self-generated key. The AKA protocol is further illustrated inFIG. 6, whilst FIG. 7 illustrates the modules implemented in a UE tosupport the AKA and key exchange protocols (the dotted lines in FIG. 7identify components which should be contained within a tamper resistant“module” for increased security.

The mechanism described in the preceding paragraph assumes that thevisited network(s) is(are) trusted. If this is not the case, then asolution is to allow a mobile terminal to generate a keyk_(c)′=KDF2(k_(i), rand), where KDF2 is another key derivation functionbut which is crypotgraphically independent of KDF. Independence of KDFand KDF2 may be achieved either by using completely different functionsor, if the first function is a block cipher KDF(k,r)=E(k,r), a simpletransformation could be used to obtain the second function, e.g.KDF2=E(k XOR m,r) for some fixed bit-mask m. (Of course, otheralternative solutions exist.) The two keys generated by the mobileterminals are used in the Diffie-Hellman exchange. As the visitednetworks do not know KDF2, they cannot derive the keysk_(c)′_((A and B)). If it is required to perform lawful interception ata visited network, then the secret key k_(c)′ of a terminal can be sentfrom the terminal's home network to the visited network. Lawfulinterception can be performed at the home network providing that thevisited network first provides the sniffed value g^k_(c) to the homenetwork and that encrypted traffic is subsequently forwarded to the homenetwork.

With this mechanism it is not possible for a visited network to confirmthat a terminal is indeed using the agreed secret key k_(c)′. This iseasily solved by allowing the visited networks to exchange the sniffedvalues g^k_(c(A and B)), and comparing the values which were sent withthe values which should have been sent. This still does not allow avisited network to intercept traffic without first having received thekey k_(c)′ from the home network.

Still further modifications can be made to the embodiments describedabove, as will be appreciated by the person of skill in the art. Forexample, rather than Diffie-Hellman, MTI, station-to-station protocol,etc may be used to agree upon a PMK between the mobile terminals. Usingmulti-party variants of the key exchange protocols, it is possible toset up a secure teleconference between multiple terminals.

In the embodiments described above, it has been assumed that the secretkey k and the pseudo-random function PRF are stored on the subscriber'sSIM card. As SIM cards become more sophisticated, including some levelof processing power, it is possible that the entire process ofgenerating the PMK will be done on the SIM card. To further illustratethe invention, another embodiment will now be described. This embodimentemploys the invention at the SIP (application) level and can forinstance be used in the case of user-to-user IP multimedia traffic. Theexample is based on current 3GPP specifications, but is clearly notlimited thereto. It is assumed that the UEs wishing to establish asecure session have already registered with respective visited networksto get network access. This would typically involve performing the AKAprocedure between the UEs and respective GGSNs and home networks. Asecond AKA procedure, known as IMS AKA (see IETF RFC3310) is used toauthenticate a UE at the SIP level. The invention takes advantage of theIMS AKA procedure to generate session keys in a way which does notintroduce additional signalling load.

The Session Initiation Protocol (SIP) has been introduced above.However, a more detailed description may be helpful. This descriptionuses the following abbreviations:

-   -   CSCF Call Server Control Function    -   CN Core Network    -   HTTP Hyper Text Transport Protocol    -   IMPI IMS Private Identity    -   IMS IP Multimedia Subsystem    -   SEG Security Gateway    -   SDP Session Description Protocol    -   SIP Session Initiation Protocol    -   SADB Security Association Database    -   SPD Security Policy Database    -   UAC User Agent Client    -   UAS User Agent Server

SIP is a control protocol which can initiate, terminate and modifymultimedia sessions and is specified in IETF RFC 2543 (1999) SIP:Session Initiation Protocol. Multimedia sessions include, e.g. voicecalls, videoconferences, streaming and chat. It is common that theSession Description Protocol (SDP) {as described in IETF RFC 2327 (1998)SDP: Session description Protocol} is used in conjunction with SIP tospecify the sessions and negotiate the codecs to be used. A user can bereachable at different IP-addresses, i.e. terminals, depending upon theregistration process. In the registration process the user registers theidentities and the corresponding IP addresses.

SIP is based on HTTP and works in a similar way, i.e. it is based on aclient-server model. Hence an entity is either sending requests as aclient or responses as a server. A SIP transaction has happened when therequest has triggered a response and the client has received theresponse.

A number of different entities are in use when SIP is used. These are:

User Agent

The user agent interacts with the user, e.g. when the user invites (setsup) a voice call with another party. A user agent is either a client ora server depending on whether it originates requests or returningresponses.

Proxy Servers

A proxy server can be Call Stateful, Transaction Stateful or Stateless.A stateless proxy does not store any states, i.e. it only forwards therequest and from the Via header it can route a response. A call statefulproxy stores state parameters from the start of a session with an INVITEuntil that session ends. Such a proxy can measure the length of a call.Note that all subsequent SIP messages in a particular session will berouted through a Call Stateful Proxy. A Transaction Stateful Proxy, e.g.a Forking proxy, stores parameters that are only related to a particulartransaction, i.e. until the transaction is ended.

Forking Proxy

A Forking Proxy is a SIP Proxy that can try different alternatelocations for an INVITE message and this can be done in a sequential orparallel manner.

Redirect Servers

A redirect server may have information about different contact addresseswhere a particular user can be reached. If a caller tries the publicaddress of a friend, then the UA of the caller will receive a number ofdifferent alternate addresses from the redirect server at which thefriend can be located. The UA of the caller then can try all of thesealternatives.

Registrars

A registrar accepts registrations, i.e SIP REGISTER. A SIP user can tellthe Registrar, which address the user is reachable at.

There are six different “mechanisms” defined in SIP that can be includedin requests

INVITE

An INVITE is sent from a user to other users or servers with which thatuser wants to set up a session, e.g. a videoconference or streaming.

ACK

SIP uses a three-way handshake for INVITEs. This is the only methodwhich is three-way—all other methods are two way. This enables the useof forking proxies. Furthermore it also takes into account that fordifferent reasons the invited party may consume take considerable timebefore actually accepting the invitation. The originating user sends anACK when the invited user has accepted the call. At this point allinvolved parties have verified that the INVITE is still valid.

OPTIONS

OPTIONS is used for identifying the capabilities of a server, e.g. whatmethods it is supporting.

BYE

A BYE is sent for terminating a session.

CANCEL

A user may have sent an INVITE to another user. Before an ACK has beenreturned the user that sent an invitation might for different reasonsterminate the transaction using a CANCEL.

REGISTER

A REGISTER is sent by the user towards a registrar in order to notifythe server of the IP address at which a user can be reached.

The procedure for setting up a “call” using SIP is illustrated in FIG.8. In this case the user agent, which is acting as a client or UAC,sends an INVITE to the UA of a friend that will act as a server or UAS.The UAC sends the SIP INVITE (1) towards a Proxy Server, which willcommunicate (2) with a DNS server in order to find out the address ofthe next hop. The Proxy Server forwards the SIP INVITE (3) and this timethe Proxy Server needs to communicate (4) with a Location Server inorder to find out the IP address of the receiving party and then forwardthe INVITE (5). The User Agent Server will send back response to theUAC, which in SIP has the syntax 180 RINGING. The UAC then knows thatthe message has been received by the UAS. In this situation the UAC maydecide to terminate the call, e.g. because it took too long for the UASto answer. In that case the UAC sends a SIP CANCEL to which the UASresponds with a SIP 200 OK. If the user decides to answer the call theUAS will send back a SIP 200 OK and the UAC will send a SIP ACK towardsthe UAS indicating that the call is still fresh. Note that packets canbe lost and therefore the ACK mechanism is needed. This is the so-calledthree-way handshake. Now the session starts, e.g. by using RTP asspecified in IETF RFC 1889 (1996) RTP: a transport protocol forreal-time applications. (NB. The SIP protocol is undergoing some majorchanges, e.g. reflecting 3GPP requirements as can be found in IETF RFC2543bis-09 (2002) SIP: Session Initiation Protocol.

The 3GPP IMS is a CN within UMTS and is based on SIP. There are fourentities of interest in regards to SIP in IMS:

-   The UE (The user equipment)    -   Contains the UA-   The P-CSCF    -   Acts as an outbound proxy. This is the first contact point for        the UA in the UE located in the visited network. It forwards SIP        requests towards the I-CSCF. Note: If the GGSN resides in the        Home Network then the P-CSCF will also be in the Home Network.-   The I-CSCF    -   This is the contact point in the home network and acts as a SIP        proxy. It forwards SIP requests or responses towards a S-CSCF.-   The S-CSCF    -   This may behave as a Registrar, a Proxy Server and a UA. Before        the UE can send an INVITE it has to first register a public        identity or an IMPU successfully. The registration of an IMPU is        done by the UE sending a REGISTER towards the Home Network. The        HN issues a challenge towards the UE. The identity that is        authenticated is the private identity or the IMPI and the        authentication is performed by the S-CSCF.

FIG. 9 illustrates a scenario were an INVITE is sent from one UE toanother UE, both UEs residing in a 3GPP network.

For the first and the last hop (between the UE and P-CSCF), IPsec ESP isused as specified in 3G TS 33.203: “3^(rd) Generation PartnershipProject (3GPP); Technical Specification Group (TSG) SA3; Access Securityfor IP-based services, (Release 5). (Note: this protection is for theSIP signalling, not for the actual user traffic.) Sensitive data will beexchanged between the Visited Network and the Home Network using the SIPprotocol. It is therefore a requirement that inter-network SIPsignalling is protected by a SEG.

Key Management

The session key for integrity protection is derived from the IMS AKAprocedures. When the UE sends an unprotected REGISTER message, uponreceiving this message the Home Network (HN), i.e. the S-CSCF, issues achallenge towards the UE. The SIP message containing the challengeincludes the session key tailored to the P-CSCF whereas the UE derivesthe same session key from the challenge. This procedure is as describedabove and involves the sending of the rand, XRES, and k_(c) parametersto the P-CSCF, and the forwarding of the rand parameter to the UE.

IKE

IKE is used for negotiating IPsec SAs for protecting SIP signallingbetween the visited network and the home network.

What is important to keep in mind is that only the SIP signalling goesthrough the IMS (the CSCF nodes), the actual user data payload will becarried over a protocol like RTP, sent over the normal GPRS (GGSN)network. Therefore, the key management (e.g. MIKEY) will typically bepart of the SIP signalling in IMS, whereas the actual security (e.g.SRTP) is applied to packets sent over another path in the overall GPRSnetwork.

With the above introduction on IP Multimedia call set-up, we nowdescribe an exemplary way how the present invention can be used toperform interception of end-to-end protected (e.g. using SRTP) IPmultimedia traffic compliant with 3GPP standards, without any changes toexisting standards. For simplicity, we shall assume a Diffie-Hellman keyagreement (e.g. using MIKEY) is used between the users, though it willbe clear to those of skill in the art that the other methods previouslydescribed (using pre-shared or public keys) can be used as well withcorresponding modifications.

As mentioned above, when a user A performs a SIP registration, he willderive a key, k, for protecting the SIP signalling between him/her andthe P-CSCF in the visited network. Using k, keying material x can bederived (e.g. setting x=k in the simplest form). User A now uses g^x forhis Diffie-Hellman value sent (e.g. by MIKEY as part of a SIP/SDPmessage) to user B on call set-up. Similarly, user B obtains key y, andsends g^y back in the similar way. The respective networks can now,using the known exponent x (or y), and the “sniffed” g^y (or g^x)perform lawful interception by forwarding corresponding keying material(e.g. x from the P-CSCF and g^y from the GGSN) to the interceptionpoint, and then forwarding the actual traffic (encrypted) from the GGSNnode it passes to the interception point. Note that if the invention isused with 3GPP IMS specifications, no existing, standardisedcommunication interface needs to be changed.

Of course, all the previously mentioned extensions, e.g. using a secondlevel of key-derivation, KDF2, to only allow the Home Network to performinterception is applicable here too, as can be easily seen by those ofskill in the art.

1. A method of facilitating the lawful interception of a data sessionbetween two or more terminals, wherein said session uses encryption tosecure traffic, the method comprising: storing a key allocated to atleast one of said two or more terminals, at the at least one terminaland at a node within a network through which said session is conductedor at a node coupled to that network; prior to the communication of asession setup request from a calling terminal to a called terminal,exchanging a seed value between the at least one terminal and said node;using the key and the seed value at the at least one terminal togenerate a pre-master key, the pre-master key subsequently becomingknown to each other terminal involved in the data session and using akey exchange procedure to transmit a first cross-parameter from the saidat least one terminal to another terminal and to transmit a secondcross-parameter from the other terminal to the said at least oneterminal; and directly or indirectly using said pre-master key toencrypt and decrypt traffic associated with said session.
 2. The methodof claim 1, wherein said node generates the pre-master key for use inlawful interception of the data session.
 3. The method of claim 1,wherein said key exchange procedure is a Diffie-Hellman exchange.
 4. Themethod of claim 3 further comprising detecting at said node, or atanother node through which session traffic passes, the exponentiation ofa second key sent to the at least one terminal from a peer terminalduring the Diffie-Hellman exchange, and generating the pre-master keyusing detected exponentiated second key and the second key of the saidat least one terminal.
 5. The method of claim 1, further comprisingapplying a key derivation function to said key and the seed value toderive an exponentiation of the second key then being generated for usein the Diffie-Hellman exchange.
 6. The method of claim 1, wherein thesteps of exchanging the seed value between the terminal and the networknode, and of generating the pre-master key are carried out each time anew data session is to be established.
 7. The method of claim 1, whereinthe steps of exchanging the seed value between the terminal and thenetwork node, and of generating the pre-master key are carried out forevery data session regardless of whether or not lawful interception isrequired.
 8. The method of claim 1 wherein the pre-master key is used bythe terminals involved in the data session to generate one or moretraffic encryption keys, the traffic encryption keys being used toencrypt the traffic associated with the data session.
 9. The method ofclaim 1, wherein said node is a node of the home network with which theuser of said at least one terminal has a subscription.
 10. The method ofclaim 1, wherein said at least one terminal is attached to a foreignnetwork, and the seed value is sent to the terminal via the foreignnetwork.
 11. The method of claim 1, further comprising generating thesecond key at said node of the home network, sending the key to theforeign network together with the seed value, and sending the seed valuebut not said second key to the terminal.
 12. The method of claim 1,wherein said data session is an IP data session.
 13. A method offacilitating the lawful interception of a data session between two ormore terminals, wherein said session uses encryption to secure trafficand at least one of the terminals is a mobile wireless device, themethod comprising: storing a first key allocated to said at least oneterminal, at the at least one terminal and at a node within the at leastone terminal's home network; using the first key to authenticate the atleast one terminal when the at least one terminal registers with thehome network or a visited network; using the first key and a seed valuesent from the home network to the at least one terminal to encrypttraffic end-to-end during said data session; generating a second key atthe mobile terminal using the seed value and the first key; andperforming a Diffie-Hellman exchange using said second key.
 14. Themethod of claim 13, wherein said step of using the key to authenticatethe terminal uses the authentication and key agreement (AKA), protocol,this protocol also making use of the key to secure data sent over aradio link.
 15. The method of claim 13, wherein said step of using thekey to authenticate the terminal comprises using the key to generate achallenge value at said node and a response value at the terminal,comparing the challenge and response values, and authenticating theterminal only if the values match.
 16. The method of claim 13 comprisingsending the key and the seed value to a lawful interception authority,wherein user traffic to be intercepted is forwarded to the lawfulinterception authority from the access network, and the authority canuse the received key and seed value to decrypt the forwarded traffic.17. The method of claim 16, further comprising sniffing one or moreparameters associated with a key exchange protocol between saidterminals in the access network, and forwarding these to the lawfulinterception authority with said key and seed value.
 18. A method ofsecuring data transmitted between a plurality of terminals, each ofwhich is attached to a communications network, at least one of theterminals having allocated to it a home network, the method comprising:sending a seed value from the home network to the at least one terminal,via the corresponding communications network, as part of a callsignalling level authentication procedure; and using said seed value atthe at least one terminal to generate one or more traffic encryptionkeys for use in the end-to-end encryption of traffic associated with acall between terminals; and forwarding said seed value to a lawfulinterception authority to allow that authority to compute the trafficdecryption keys, whereby when a call is setup encrypted traffic can beforwarded to the authority for decryption.
 19. The method of claim 18,wherein said at least one terminal is a mobile wireless terminalattached to a mobile communications network.
 20. The method of claim 18,comprising storing a secret key at said at least one terminal and in thehome network, and sending that key or a key derived therefrom from thehome network to said communication network for use in saidauthentication procedure, the sent key also being used by the wirelessterminal to generate said traffic encryption keys.
 21. The method ofclaim 18, wherein the step of generating one or more traffic encryptionkeys comprises performing a key exchange procedure between theterminals.
 22. The method of claim 18, wherein Session InitiationProtocol is used to setup and control calls between terminals.
 23. Themethod of claim 18, further comprising sending said seed value from aS-CSCF node of said home network to the at least one terminal, via aP-CSCF node of said communication network.
 24. The method of claim 18,wherein said call signaling level authentication procedure is an IMS AKAprocedure.
 25. A method of communicating data between a first terminaland a second terminal on an end-to-end security basis, the firstterminal being served by a first network, and the second terminal beingserved by a second network, the method comprising: a firstauthentication and key agreement sub-procedure involving transmitting afirst set of values from the first terminal's designated home operatorto the first network and on the basis thereof deriving at least onefirst encryption parameter to be used by the first terminal; a secondauthentication and key agreement sub-procedure involving transmitting asecond set of values from the second terminal's designated home operatorto the second network and on the basis thereof deriving at least onesecond encryption parameter to be used by the second terminal; a keyexchange sub-procedure involving transmitting a first cross-parameterfrom the first terminal to the second terminal and transmitting a secondcross-parameter from the second terminal to the first terminal, and acommunication phase where the first terminal and the second terminalexchange information via a connection being end-to-end encrypted in thefirst terminal on the basis of the at least one first encryptionparameter and the second cross-parameter, and in the second terminal onthe basis of the at least one second encryption parameter and the firstcross-parameter.
 26. The method of communicating data according to claim25, comprising intercepting the information exchange between the firstterminal and the second terminal in at least one of the first network,based on the first encryption parameter and the second cross-parameter,and the second network, based on the second encryption parameter and thefirst cross-parameter.
 27. A first terminal for communicating data withat least one other terminal on an end-to-end security basis, the firstterminal being served by a first network, the at least one otherterminal being served by a second network, the first terminalcomprising: a first encryption unit, adapted to request a first set ofvalues from the first terminal's designated home operator and receive atleast one first encryption parameter; a memory for storing a keyallocated to at least one of said terminals, at the first terminal andat a node within a network through which said session is conducted or ata node coupled to the network; means for exchanging a seed value betweenthe first terminal at which the key is stored and said node prior to thecommunication of a session setup request from the first terminal to theat least one other terminal; means for generating a pre-master key usingthe key and the seed value at the terminal, wherein the pre-master keysubsequently also becomes known to each other terminal involved in thedata session; means for using the pre-master key to directly orindirectly decrypt data at the node within the network or at anothernode to which the pre-master key is sent; a key exchange unit, adaptedto transmit a first cross-parameter to the at least one other terminaland receive a second cross-parameter from the at least one otherterminal; and a data transceiver for exchanging information with the atleast one other terminal via a connection being end-to-end encrypted onthe basis of the at least one first encryption parameter and the secondcross-parameter.
 28. A method of facilitating the lawful interception ofa data session between two or more terminals, wherein said session usesencryption to secure traffic, the method comprising: storing a keyallocated to at least one of said terminals, at the terminal and at anode within a network through which said session is conducted or at anode coupled to that network; prior to the communication of a sessionsetup request from a calling terminal to a called terminal exchanging aseed value between the terminal at which the key is stored and saidnode; using the key and the seed value at the terminal to generate apre-master key, wherein the pre-master key subsequently also becomesknown to each other terminal involved in the data session; generatingthe pre-master key at said node and using the pre-master key to directlyor indirectly decrypt data at that node or at another node to which thepre-master key is sent: directly or indirectly using said pre-master keyto encrypt and decrypt traffic associated with said session; and using akey exchange procedure to transmit a first cross-parameter from the saidat least one terminal to another terminal and to transmit a secondcross-parameter from the other terminal to the said at least oneterminal.
 29. The method of claim 28, wherein said node generates thepre-master key for use in lawful interception of the data session. 30.The method of claim 28, wherein said key exchange procedure is aDiffie-Hellman exchange.
 31. The method of claim 30, further comprisingapplying a key derivation function to said key and the seed value toderive a second key, an exponentiation of the second key then beinggenerated for use in the Diffie-Hellman exchange.
 32. The method ofclaim 28, wherein the steps of exchanging the seed value between theterminal and the network node, and of generating the pre-master key arecarried out each time a new data session is to be established.
 33. Themethod of claim 28, wherein the steps of exchanging the seed valuebetween the terminal and the network node and of generating thepre-master key are carried out for every data session regardless ofwhether or not lawful interception is required.
 34. The method of 28,wherein the pre-master key is used by the terminals involved in the datasession to generate one or more traffic encryption keys, the one or moretraffic encryption keys being used to encrypt the traffic associatedwith the data session.
 35. The method of 28, wherein said node is a nodeof the home network with which the user of said at least one terminalhas a subscription.
 36. The method of 28, wherein said at least oneterminal is attached to a foreign network, and the seed value is sent tothe terminal via the foreign network.
 37. The method of claim 36 furthercomprising, generating the second key at said node of the home network,sending the key to the foreign network together with the seed value, andsending the seed value but not said second key to the terminal.
 38. Themethod of 28, wherein said data session is an IP data session.